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ABSTRACT 


A personnel data Base consists of integrated data 
about persons of any organization. A retrieval system 
retrieves information from this data base. The informa- 
tion may be either of a single individual or about a group 
of people. This system has been developed to retrieve in- 
formation from a relational data base containing data about 

Army Officers. The computer system chosen for this data 
base is TDC-316. The system is based on disk* This project 
was taken up as a part of data base project group. The 
other parts being 

(a) Building a Data Base 

(b) Data validation 

All the systems are written in the Basic Assembly Language 
(BAL) of the TDC-316. 



1. INTRODUCTION 


This infoimation retrieval system works on a perse- 

A 

nnel data base developed at IIT'Kanpur as a project on 
- TDC-316 computer. A personnel .data base has data about 
persons. In this case the persons chosen are army officers 
For management of army officers, there is a requirement of 
storing and retrfeving a large amount of data in an effi- 
cient manner. The old technique of storing data in multi- 
ple files, each suitable for particular application is a 

V 

cumbersom and inefficient technique. The modern data base 
with its management techniques is an ideal choice for work- 
king on such data. Out of the type of data bases available 
a relational data base offers the best scheme for flexibi- 
lity and working in an integrated fashion. This particular 
data base and retrieval system is based on the relational 
approach. 

There are large number of terms being used in data' 
bases. The terms and their meanings, as applicable in 
this study are given in the succeeding paragraphs. The 
terms definitions are generally as per Computer Data Base 
Organization by MARTIN and -from- DATE. 

Data Base 

A data base may be defined as a collection of inter- 
related data stored together with as little redundancy as 
possible to serve one or more applications in an optimal 
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fashion. The data are stored so that they are -indepen- 
dent of programs which use the data. A common and con- 
trolled approach is used in adding new data and in modi- 
fying and retrieving existing data within the data "base. 

An integrated data base contains data for many 
applications. It is a repository of information needed 
for running some organization. In our case the organi- 
zation is the army. A data base may be organized for 
batch processing, real time processing or in-line proce- 
ssing where single transaction is completed one at a time, 
without the constraints of real time processing. Our 
system approximates to INLINE processing. 

Advantages of having data bases against the con- 
ventional tape library systems have been explained by 
various authors. The biggest advantage is having contro- 
lled minimal redundancy with its accompaniment of 

low cost storage 
single updating run 
consistancy. 

One of the most important characteristics of data bases is 
the case of restructuring data storage without change in 
application programs. This is termed Data Independence. 
Data Independence 

It implies that data, and the programs which use this 
data, are mutually independent and each may be changed 
without affecting the other. The application programmer Is 
insulated from changes in data storage. He need not know 
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how and where they are stored. This also gives some measure 
of security and privacy. Unanticipa.ted questions may he 
asked from the data base. The application programs are 
interested in logical organization. 

Logical and Physical View 

A logical data description refers to the manner in 
which a programmer sees the data. It may or may not (more 
often not) coincide with a physical data description which 
refers to the manner in which data is stored physically on 
devices. Programmer sees the logical relationships and 
logical data structures. He requires a logical chain of 
records, which may not he the physical chain. Software 
converts programmers logical statements to the physical 
reality. 

SCHEMA 

The logical description of a data hase used hy the 
data hase software is called SCHEMA. A schema is a chart 
of the types of data that are used. It gives the names of 
the entities and their attributes and specifies the 
relations between them. It is a frame work into which the 
values of data items can he fitted. The values may change 
from time to time. Any particular set of values in the 
schema is called an instance of Schema 1 . Schemas are 
often drawn in the form of block diagrams. They are also 
called *Data Model*. 
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The following terms which have been used in defining 
SCHEMA are themselves defined. 

Data Item 

A data item is the smallest unit of named data. It 
is referred to as a field or data element . 

Data Aggregates 

It is a collection of data items within a record which 
is given a name and referred to as a whole, e.g. , Data may 
consist .of year, month and day. 

Record 

A named collection of data items or data aggregates. 

An application program reads a logical record. 

File 

A file is a named collection of all occurrences of a 
given type of record. 

Entity 

Items about which we store information are referred 
to as entities. An entity is a tangible object such as a. 
person a part of inventory or a plane. It may be non- 
tangible such as an event, a, customer account. We record 
the properties of the entities. The information is called 
an entity record. It is called a logical record by appli- 
cation programme and a stored record by the physical 
storing mechanism. 
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At tr ibut e s 

The property of an entity is called an attribute. 

These attributes have values such as personal number, 
rank, address, account number etc. These attributes 
are stored as data items in byte strings;;- 
FL AT E TIE 

The nrorrelation between values, attributes and en- 
ties is normally most easily stored in a fixed sequence 
in two dimensional ta/bular form, called a flat file. A 
scheme of flat file is shown in the Figure 1-1, 

Each row of the table represents one entity. Each 
column of the table refers to an attribute. The name of 
the attribute is given in the top of the table. An attri- 
bute the value of which identifies an entity uniquely is 
called an Identifier or key . In the case shown, personal 
number acts as the key. The grouping of data items repre- 
sents a relationship between these items and such a rela- 
ted set of values is also called a tuple . 

Subschema, 

A subschema is an application programmer’s view of 
the data he uses. Many subschemas can be derived from 
a single schema. The application programmers do not 
necessarily see the schema. With the subschema, the schema 
and the physical organ izs.t ion, there are three view of data. 
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A PLAT PILE 



Attribute 

1 

Attribute 

2 

Attribute Attribute 

3 4 

Key 

Personal No. 

Name 

Date of 
birth 

Addre ss 

Entity 

1 

IC-001 

Ravi 

12 Dec. 1940 

XX 

2 

IC-610 

Madhav 

15 Sept. 193 3 

XX 

3 

IC-200 

Deepak 

8 Marc. 1943 

XX 

4 

IC-300 

Ram 

1 Apr, 1950 

XX 

5 

IG-400 

Raji 

2 Jun. 1956 

XX 


Pig* 1-1 
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(1) Subschema : application programmer's view 
also called Data Sub Model. 

(2) Schema or Global logical data base descrip- 
tion as seen by the data base administrator. 

Also called DATA MODEL. 

(3) Physical Data Base Description; A chart of 
the physical layout of the data on storage 
devices seen by systems programmers. 

The system software provides mapping between these 
different views. Thus a data base management system will 
have a presentation as shown in Figure 1-2. (MiRTIN 
Figure 7-2.) 

This system ensures logical data independence which 
means that the overall logical structure of the data may 
be changed without changing the application programs. 

It also has physical data independence which means 
that the physical storage may be changed without changing 
either the overall logical structure of the data or the 
application programs. 

Relational Data Base 

Once the logical d.ata ihdependence has been achieved 
the over riding consideration in design of dal a base is 
the convenience of the majority of applies! ion programmers. 
The description of data should be under stobd easily by the 
users, such as a description is achieved by using two dimen- 
sional flat tables. Any complex representation such as 
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storage 


Figure 1-2 
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tree or plex structures can also Toe reduced to a flat file 
representation by a simplification process called norma- 
lization. A flat file tabular representation is called a 
reflation.. A data base constructed using relations is 
called a relational da.ta base. 

It should be possible to extract subsets from such 
a table and also to join such subsets giving a flexibility 
to the user in information retrieval. This retrieval will 
consist of selecting different columns for an entity and 
the ability to combine them. The characteristics of such 
i data base will be 

1. Bach entity in a relation represents one 
data item. 

2. The relations are column homogeneous i.e., 
all items in a column are of same type. 

5. Bach column or attribute ha„s a distinct 
name. 

4. Bach row is distinct. Duplicate rows are 
not allowed. 

Information Betrieval 

Information retrieval from such a base can be done 
in any sequence of rows and columns. Bach entity has 
one identifier attribute which is unique. In some relation 
there may be more than one attribute to identify the entity. 
These identifiers are also called keys. These keys have two 
properties: 
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(a) -unique identification 

(b) non-redundancy . 

Where there are more than one keys, one of then is 
termed as primary key. Most of the search is done on pri- 
mary key. In our system, an approach akin to relational 
calculus is adopted. The user simply defines the results 
he wants and leaves the system to decide what operations 
are necessary to extract that information. It is like 
defining a new relation which is to be derived from the 
existing relations in the ba.se. Sometimes it is advocated 
that binary relations (relations having binary tuples) 
offer the maximum flexibility for random queries in an 
unanticipated fashion. This however increases the house 
keeping jobs of the system software. Our data base is - 
not based on binary relation, however, a large number of 
queries of unanticipated types can be answered. 

Army Officers Data Base 

The army has a large number of officers. Maximum 
possible information on each has to be kept. At present 
about 150 different attributes can be easily identified. 

The users are the various departments of the army which are 
interested in reports as below. 
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(a) strength of officers in the army 

(b) strength of officers in the various corps 

(c) pay and accounts 

(d) qualification *n • ■j'- . . 

(e) pensions 

(f) recruitment through various academies 

(g) selection of officers for various courses 
and appointments. 

Most of the army officers movements are done corpswise 
L s such it is beneficial to have a relation which is organi- 
zed with corps as primary key. But this key will be repeated 
this type of file is called an inverted file. Other rela- 
tions are organized 0 ^ personal number as the primary key. 
Every officer has a unique personal number. The user depar- 
tments give their subschemas, which consist of two or more 
attributes. The system extracts this infoima.tion from the ; 
da,ta base. The system developed here does not do the pay 
and accounting though this can also be done with slight 
modifications. This information system prepares lists of 
officers as out put. Bor manipulation end calculations, 
simple programs have to be written. The system is a pilot ! 
system for a personnel data ba.se developed specifically 
on TDC-316. Due to limitation of time and the availability 
of computer simplicity in design of programs has been the 
key. The system can be easily expanded to suit any unanti- j 
cipated query requirement. This thesis has been organized 
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manner: 

Part I: System Constraints and General 
Consider actions . 

Part II: Description of Relations and Common 
Data Structures. 

Part III: Query Translation. 

Part IY: Access Mechanism. 

Part Y: Processing and Output. 

Program listing and instructions for working the system 

have been included as appendices. 



2. SYSTEM CONSTRAINTS 


Introduction 

The retrieval system starts from the projection of the 
query. The query has to he recognized, analysed and then 
used to define data structures which are used hy seek and 
processing routines. The information is then located, pro- 
cessed and put in the output buffer. The output routines 
then give a print out as per the subschema of the user. 

Such a system can be as powerful as desired with a 
very wide range of features. These again are controlled by 
the following factors: 

(a) The computer used 

(b) The language used 

(c) The memory available 

(d) Complexity of the system 

(e) System speed 

(f) Generality of the system 

(g) Time available to generate the system. 

These factors as applicable to this system are described 

in the following paragraphs. 

Computer 

The computer to be used is TDC-316 with the following 
configuration: 
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1. oru 

2. Memory 28K 

3. Card reader 

4. Disc lack - 7.6 M bytes 

5. Printer 

6. Paper tape reader 

7. Paper tape punch 

8. Key board/teletype. 

This configuration can have only card reader/keyboard/paper 

tape 

as the input device and line printer/paper tape punch as 

output device. The system is disc based. 

la nguage 

There are two languages available: 

1. FORTRAN 

2. Basic assembly language, BAD. 

The BAAL assembler is not relocatable and as such FORTRAN 
and BA£ routines cannot be called by each other. FORTRAN has 
an added restriction in use of disc. It can access the disc 
only in the serial mode. It was decided to use BAX as the 
language for system development. 

Memory Available 

The main memory available with BAD is 28K words. Bach 
word in TBC-316 consists of 2 bytes of 8 bits each. Bach 
byte is seperably addressable. The 'lower byte has even 

address. For word addressing the location counter has to be 
incremented by 2. The secondary memory available is a disc 
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pack of 7.62 M bytes. There are 202 usable tracks/cylinders, 
10 surfaces and 10 sectors/surf ace/track. Bach sector of 
disc can store 256 bytes. Bvery sector is addressable through 
a surface and sector register word in the disc controller. 
Complexity of System 

The complexity of the system is judged by the number 
and type of software routines, then lengths and the facili- 
ties provided. The levels of nesting of subroutines, gene- 
rality and sophistication of input/ output requirements are 
other factors. 

This system is totally modular in construction. The 
routines are kept small in size and designed for optimum 
efficiency in working time and space. The number of pointer 
and flags have been kept to a minimum 
System Speed 

The algorithms have been designed to exploit all the 
features of the assembler to reduce working t ime and space. 

The movement of data between the memory and the disk is kept 
at the bare minimum. This has been achieved b.y avoiding 
creation of intermediary files on disc while processing 
conditions. 

Example 

Let us say the set of conditions is as per the table 
given below. 
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Sr. No. 

Relation 

Field 

( attribute ) 

Condition 

Value 

1 

R1 

FI (RANK) 

EQUAL 

CAPT . 

2 

R1 

F4 (ARM) 

L.T. 

Arty 

3 

R1 

F6 (Service) 

G.T. 

5 years 

4 

R2 

F2 (Qual) 

EQUAL 

B.Sc. 

l 

R2 

F8 (POINTS) 

GTE 

4 

6 

R3 

F15 (Age) 

L.T. 

26 year 


Table 2-1. Set of Conditions 


The conditions show that we have to process 3 Rela- 
tions R1,R2,R3, We can do either of the following 

(a) Search relation R1 completely. Create an 
intermediary file containing list of officers 
meeting conditions 1,2,3 pertaining to Relation 
1. Then we process Relation R2 and extract 
another intermediary file II. Wnich will have 
a list of all officers satisfying conditions 

1 to 5. Finally we obtain the final list or 
file after Relation 3. In this case two inter- 
mediary files will have to be created on disc. 

(b) The second approach will be to process relations 
R1,R2,R3 simultaneously. Processing of every 
officers record is through a filter made up of 
JOIN or logical AND of all the conditions. An 
output record is created only when all six 
conditions are satisfied. No intermediary files 
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are created. 

In the second approach., movement "between the memory and 
disc is cut down. However, space is required for. processing 
more than one relation in the memory. It will be seen than 
in the absence of inverted files, no extra, space is required. 
For every inverted file, an extra buffer is required and 
pointers have to be kept for the last record processed in 
every relation. This design uses the second approach. 
Generality of the System 

The algorithm have been designed in a most general fa- 
shion to suit any personnel data base. To achieve maximum 
efficiency for this application. Certain data structures 
have limited size and width. For example, condition tables 
has a variable field width of upto 8 bytes, i.e., fields of 
lengths upto 8 bytes can be used for search criteria. These 
sizes can be varied easily to suit any other data base appli- 
cations. The dialogue between the user and the computer may 
have to be varied slightly. 

Time Availability 

Time availa.ble for generation of this system has been 
limited by the M.Tech. program length. Many more features 
can be added to the existing facilities. Some suggestions 
are made in the last chapter. 



3. ORGANIZATION OR RELATIONS AND 
DIRECTORIES 

This chapter deals with the organization of data and 
the data structures that help to locate the physical address 
of the desired information. 
layout of Relations 

A relation consists of a set of similar records. A 
record consists of two or more fields which are interrela- 
ted. These fields are placed adjacent to each other in a 
record. Records are placed adjacent to each other in memory . 


tabular representation of a 

re lati on 

i s 

shown in Figure 

Field 

F j e id- 

Field 



A 


C 



CART. 

123 

10 


RECORD 1 

LT. 

122 

6 


RECORD 2 

MAJ. 

124 

7 


RECORD 3 

In memory the 

representation rill 

be 


RECORD 1 

RECORD 2 

MAJ. 

3.24 7 


Figure 3-1. J-iayout of a Relation,. 


Each of these relation ,ias a particular field as primary 
key for identifying records. Some relations use more than or." 
keys especially inverted fill "s. A primary key is used to 

18 
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RELATIONS DIRECTORY 


Kela- Kela- Pom- length Pointer ho. ox Total 

tion tion ter of PD to Index entries No. 

Name ca ll to list in memory in INDBF of 

FDLIST records 

in 


Na- KELNM HE LID PTRFDL N0F1D MINX NIND TO EEC 

me 


Si- 6 2 1 1 2 1 2 

ze 


Exam-G-RPS 0 1 40,000 4 60 , 000 20 6,000 

pie 



Current 

Record 

No. 

P rimary 

key 

field 

Format 
of pri- 
mary 
key 

Secondary 

key 

field 

Format 

Name CRCNO 

KEYRP 

FMKRP 

KEYRS 

FNERS 

SIZE 2 

2 

2 

2 

2 

Example 20 4 

07 

3 

05 

8 
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.0 locate a group of records and a secondarykey used to 
locate a particular record out of that group. A relation 
of this type in this data base is RELATION ARM which uses the 
field CORTS to identify all officers belonging to a particular 
corps of service and then uses the officers personnel number 
to select a unique record,, 

Relation Directory 

The logical organization of relations is c define fi- byi" t 
a data structure named Relations Directory . Its layout is 
given in the table listed on the opposite page. This direc- 
tory gives all the particulars needed for processing. Its 
components are described below: 

1. RECNM gives the relation name. It ma.y consist of upto 

6 characters. 

2. RELATION COLE Each relation is given a code number. In 
REEIL 

our case it happens to be the serial number in the 
directory. 

3. POINTER TO LIST OE FIELDS It gives the address of the 
PTRFDC 

list of fields which form this relation. 

4. LENGTH OF FIELD LIST It gives the number of fields in 
NOFD 

that relation. 

5. AMINX It gives the local ion of the relations index 

table in memory. This INDEX table is a physical 
layout of the relation. 
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6. NINL It gives the number of entries in the primary 

index table. It shows the number of disc 
cylinder being used by that relation. 

7. TOTRBC Gives the total number of records. 

8. CRCNO Gives the current record number. 

9. KEYBT Gives the primary key of that relation. 

10. FMERT Gives the length of the primary key. 

11. KEYRS Gives the secondary key. 

12. FMKRS Gives the length of the secondary key. 

Field Directory 

This directory is maintained to store the information 
about the fields used by the system. The layout of this 
directory is given below. 


Field Code 


Address of 

Relations Name length 
list 


Field List 


This list is maintained to co-relate relations fields. 
It has the following fonnat 


Field Identi- FORMAT F'DIST 
fication No. 

This field list structure is used by the query inter- 
pretation part to fill up other data structures which are 
necessary for processing the query. Its description is 
as follows. 
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Field Director 


Field 

Code 


Address of ~~” 
relations Name 

list 


Length 


Field list 



FD ID 

FOBMAT 

F Dist 

FD 

ID 

Belati on 
ID 

Length Type 

Distance from 
■beginning of 


2 Bytes 2 Bytes 


1 Byte 


Figure 3-3 



PL' ID 
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It is a t»« byte field. First byte gives the Relation 
Number and the second byte &ives the field number. 

FOMAT 

It is two byte field. First byte gives the length of 
the field and the second byte gives the type of field whether 
alphanumeric or numeric. 

FPIST 

It gives the distance in bytes of this field from the 
beginning of the record. 

The routines take the required information from these 
tables and construct other data structures for their own use 
in SEEK, SEARCH and PROCESS. These will be described in the 
following chapters. 



4. MAIN SCHEME MD DATA STRUCTURES 


Objectives 

The objectives of the personnel data base retrieval 
system may be of the following types. 

(a) Rind out some or all details of a particular 
officer. 

(b) Rind out some or all details of a set of 
officers who have the attributes as speci- 
fied by the user. 

The first type is termed as SING-IS QUERY . The second 
type is teimed as GROUI QUERY . Examples of each will be 
given later under query translation. Both the types of 
queries are qvdfce common. 

Requirements for tackling the Problem 

In both the type of queries the job breaks down to 

(a) Tabulate what fields are the condition fields 
which have to be matched for some values. Also 
tabulate information about their location. This 

is tabulated in TBTROC. 

(b) Tabulate what fields are to be given as output. 
These are tabulated in TBOTPT . 

(c) Tabulate the conditions, their values and fields 
which have to be matched. COME TABLE . 

(d) SUBSCHEMA of the user in final output format. 
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Action Steps 

First of all the data structures have to he huilt up 
by query translation. Once these data structures are built 
up, one relation is selected and the following steps taken 

[a] Seek the physical location of the sector 
desired. 

[b] Search the sector to locate likely record. 

[c] Scan the TBPROC for finding fields to be 
matched. 

[d] Compare these field values of the record 
against the conditional values. 

[e] If they agree, scan the TBOTPT for fields 
to be output, extract them f rom the record 
and make an output buffer. 

[f] Go and repeat Steps [a] to [e] for other 
relations mentioned in TBPROC. 

[g] Reject the first output at any time, any 
of the conditions do not match as CONI) 

TiiBIE signifies logical AND of all condi- 
tions. 

[h] Once all the relations are over the final 
output buffer is reorganized as per sub- 
schema and put out on the printer. 

The data structures used are described below: 
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Bata Structures 

The following data structures are described 

(a) TBPROC Table for processing 

Table for output combined with TBPROC 

Table for conditions. 

Subschema of the user. 


(b) TBOTPT 

(c) CORD 

(d) SBCHMA 


TBPROC /TBOTPT 

This table stores fields which are to be processed 
or output along with necessary information about their 
length and layout of the relation. The information in 
the buffer will be of the following types. 

F : ie ! Id : s 125 4 1 2* 5 4 1 2 3 4 1_ 


Record 1 Record 2 Record 5 Rec 4 

This particular relation has a record format consisting of 
4 fields of varying lengths 
FBI length 1^ bytes 

FB2 length lg bytes 

FB5 length 1^ bytes 

FB4 length 1^ bytes 

A query may require only fields 1 and 4 to be processed 
and F2 to be output. Similary other relations will have 
other fields. The tabulation will be as follows: 
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TBPROC Rel. 

Fa. 

TBOTPT 

Rel. 

FD. 

R1 

FI 


R1 

F2 

R1 

F4 


R2 

F5 

R2 

F5 


R3 

FIO 

R3 

F6 




R3 

F10 




extract these 

relations we 

must also 

have the 

details 


about the field lengths and locations of the fields within 
the relations. These two columns are added as FD1G-T (Field 
length) and FDIST (field distance from beginning of record) 
Since this information is required for both TBTROC and 
TBOTPT both these tables have been merged into one table 
with an extra, column added which stores inf onset ion about 
the treatment of the field e.g., whether this field has only 
to be accfcpui. layout of the table is as given on the facing 
page. 

The treatment of the field t skier- the following shape. 

digit action; 


Store 0 
Store 1 
Store 2 

The width of each 


Field has to be output only. 

Field has to be processed and OUTPUT. 
Fi^sld has to be processed only, 
entry is 5 bytes. The last entry will be 


zeroes in all columns to signify end of all fields, 
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IB Proc/lBOTPT 


Relation 

Field 

FD length 

FD Dist 

Treatment 

R 1 


h 

0 

2 

R i 

P 2 

1 2 

d l 

0 

R 1 

F 

4 

1 4 

d 2 

1 

h 


b 

d 5 

1 

h 

p 6 

X 6 

d 6 

0 

E 3 

P 8 

X 8 

d 8 

0 

0 

0 

0 

0 

0 

1 Byte 

1 Byte 

1 Byte 

1 Byte 

1 Byte 


Figure 4-1. Table for Processing and Output 
Tre atment 

2 = Process only 
1 = Process and output 
0 = Output only 



CONDITION TABLE 


FD 

ID 

FD Value condition 

length 2 Bytes 8 Bytes 

2 Bytes 

01 

C-12345 

Equal 

X 

XXX 

NE^ 

X 

XXX 

LB 

X 

XXX 

GE 

X 

XXX 

GT 

X 

XXX 

LT 

X 

XXX 

ANY 

Equal 

NEQ 

N ot equal 


DE 

Less than or equal to 


GE 

Greater than or equal to 


GT 

Greater than 


IT 

Less than 


ANY 

All values ok 



Figure 4-2 
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POND TABLE) 

The fields which have to he compared have their values 
and the type of comparison stored in this table. The struc- 
ture is shown in Table Ho 

Its entry length is 12 bytes. The first two bytes give 
the field identification. The next eight bytes are for the 
value and the last two bytes are for storing the type of 
comparison. 

During seek and process this table is used for matching 
values. The following type of comparisons are specifically 
allowed. 

(a) Greater than (GT) 

(b) Greater than or Equal (GB) 

(c) EQUAL 

(d) Hot Equal (HE) 

(e) Less than (IT) 

(f) Less than or equal (IE) 

(g) MY 

This table is designed for a more maxi lengths of 
8 bytes. In this application names are excluded from 
comparison. The routine which scans this table is COMP . 
SBOHMA 

This data structures holds the subschema given by the 
user. Its structure is as follows: 
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FD 

Type of 

Identity 

FIE ID 

FI 

Numeric 

F3 

Alpha 

F4 

ITume ric 


Tabid- 4-1. Subschema Data 
Structure . 


This structure is also created at the time of query 
translation, and is used at the output time. The numeric 
fields will have to be converted into byte strings in a 
printable mode. The Alphanumeric information does not need 
conversion and can be directly given as output. The con- 
version of numeric fields from byte strings into binary 
number equivalent is done to save storage space and save 
comparisons. 

These are the data structures used most often during 
processing. There are two other structures which do a mapping 
between logical address and physical address of records and 
sectors. These will be described in the chapter on the SEEK. 
From here we go onto the actual mechanism starting from the 
first step. The Query Translation . 



5. QUERY TRANSLATION 

USER Lefinition 

fcjit2 

A Query has ta parts: 

(a) set of conditions which have to he satisfied. 

(b) Set of fields which form the output in a par- 
ticular order. This lay out is also called 
the subschema. 

Both these sets may be mutually exclusive i.e., have 
no fields in common, or may not be mutually exclusive. The 
user has to define both these sets. 

Query Translation 

Systems have been developed which facilita.te the user 
in defining the conditions and subschema. They then extract 
proper information and develop _ data structures which are 
used for processing the information. Query translation then 
means filling up of the required data structures by software 
routine s. 

Example : A typical example in this case will be as 

follows. 

Subschema - output 

fbs /Man*:, # rank, #name, M late, of birth 

of the officer with 

condition 

FD# PERSONAL No. = 1000. 
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This forms a single officer query. The Group Query may 
table the shape. 

S ubschema 

FDS. #RMK, $TiME, 7 ^ ATE OF BIRTH 

of all officers with 

conditions 

FI- & Personal Ho, less than 10-2000. 

FD^ Parent Arm, equals M ARMOUR. 

This is a group query. 

Difference between a Group Query and a Single Query 

A single officer will have only one condition listed, 
his personall number. It may have any number of fields in 
the subschema. 

A group query will have more than one conditions listed. 
The personal number is always assumed as a condition as it 
forms the necessary link between different relations. 

Dialogue Between the User and the System 

An interactive system which permits the user to have a 
running dialogue while forming the query is very desirable. 
In the system designed here the user Is in full conversation 
with the system, till his query is fully translated. All 
the fields in subschema and the conditions are displayed 
before him on the keyboard. 

Choice of Input Media 

This system enables the user to define his query either 
through the keyboard or the card reader. He is asked to 
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exercisu his choice of input device. 

Security 

A code check is incorporated to authenticate the user. 
The user has to declare the code prevalent at that time. The 
DBA can change this code at his will and unauthorised user 
is debarred. 

Description of the System 

Function : The system is called AITRO/.CH. Its basic 

function is to obtain the subschema and the set of condi- 
tions required for seek and process routines. 

Data Structures Used : These are 

(a) CORD TAB I® 

(b) TBPROC / TBOTPT 

(c) SBSCHMA 

(d) FD. DIRE CTORTFDLIST . 

The COND TABDE will list the conditions specified, the 
TBPROC /TBOTPT will list the fields to be processed/output. 
SBQHMA will hold the subschema, and FD DIRECTOR! is used to 
obtain various informations about the fields specified. 

These structure s Ihave already been defined. 

Mechanism ; In the first part the system starts a 
dialogue with the user to establish his bonafide authority 
to use the system by asking him the code. Failure to supply 
this code rings a bell continuously. Other security measures 
can be suitably linked. Then the system asks him whether he 
wants re trie val/upd ate /building of data base. On being given 
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the correct answer (letter R) retrieval is allowed to begin. 
TBPROC 

The second part begins with establishing the type of 
query, whether SINGLE or GROUT. This w ill decide the 
processing. It also gives him a choice of input device, 
card reader /keyboard. The user is then asked to list the 
fields which will .have to be processed or output with that 
specification. With his specification the data structure 
TBPROC is built up. It is then printed out as a table on 
the keyboard to enable the user to verify. 

COND. TAB IB 

The third part asks for the conditions for processing. 

A set of fields with values to be matched is obtained from 
the user. Distinction is made between a SINGLE QUERY and 
GROUP QUERY. The numeric fields are converted from the key- 
board by.te string into the binary form by subroutine ENCODE. 
The condition/inequalitie s are put into COND table by sub- 
routine COND IT and the COND table is completed for use. 
SUBSCHEMA 

The fourth part obtains the user subschema and builds 
SBCHCMA data structure to be stored and used for the final 
output. It is also printed out at the keyboard. After 
build up of these structures, the routine APPROACH passes 
on to SEEK routines for further processing of queries. It 
also signals the end of user interaction. 



Subroutines Used 


This routine makes use of the following subroutine 

(a) SOM 

(b) NOWR 

(c) COEDIT 

(d) E FOODS 

Output 

(a) TBPROC 
(h) COEDTABIE 
(c) SBCHMA. 



6. ACCESS MECHANISM 


This chapter deals with the SEEK routines and data 
structures used by them to physically locate the sector 
which contains the desired information and bring it into 
the memory for processing. It has to find the track num- 
ber, the surface number and the sector number of the disc 
Sequence 

The sequence of access is - 

(a) select a relation from the query 

(b) scan the relation directory for the address 

of index tables, keylengths by routine FNDKEY. 

(c) scan the primary index table to obtain the 
track/cylinder number by routine TREES. 

(d) Bring the secondary index table i.e., the 
sector map of the track from the disc to 
memory. 

(e) scan this table to obtain the surface and 
sector number by FNCSBC. 

(f) bring the desired sector into memory by 
READ. 

(g) mark the index tables for future reference. 

The routines mentioned in the above paragraph i.e., 
FNBKBY, TREES, FNCSBC, SEA D, are assisted by two other 
routines. 



(i) OOMI which scans the COED table. 

(ii) FNBI2 forms a part of both TREES and FNCSRC. 

Physical Layout of Relations 

The relations are stored on the disk. Bach relation 
may have one or more tracks allotted to it. Every relation 
starts from afresh disk. The TEC disk has 2O0_ tracks 
(usable) each having 10 surfaces. Bach surface has ten 
sectors for every track. A sector can store 256 bytes. On 
the surface 0 of every track the first few sectors are uti- 
lized for storing the layout table for that track* The 
method of seeking a sector is described below. 

I hysical Manning 

Indexed sequential method is used for s boring and loca- 
ting the records. Two tables are kept as mapping devices — 

(a) Irimary Index Table 

(b) Secondary Index Table 
Irimary Index Table 

This table locates the track number. T^ere is one such 
table for every relation. The location of these tables are 
given in the relations directory. These labels are stored 
in main memeory. Its layout is given in the figure 6.1. 



Highest key 
in track 

Track Ho* 

Length of 
secondary 
index table 

SIZE 

Variable 

1 byte 

2 bytes 

Example 

IC-QL01254 

67 

80 


Table 6- 

-1. Primary 

Index Table 
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This table is scanned, "by subroutine TRKIS. 

Secondary Index Table 

This table helps to locate the surface and sector number. 
There is one such table for every track. This table is loca- 
ted on surface 0 of every track. Its length names as per the 
key length. Its layout is as below: 


No. of Records 
in the Sector 

Highest Key 
No. 

Surf ace 
No. 

Sector 

No. 


2 

bytes 

Variable 

1 byte 

H 

a 1 

U 

CD 

length 

51 

7 

4568 

0 

0 

Example 

51 

• 



0 

• 

1 

• 


* 

• 

25 



• 

• 

2 

• 

5 



Table 6—2 

. Secondary Index Table. 



Since there are 100 sectors on every track, there will 
be a maximum of 100 entries in a table. The length of the 
table may vary from 1 sector to 4 t‘%^5 sectors of 0 surface* 
depending upon the key length and total number of entries. 

With the help of these structures a sector is brought 
into memory. This sector then has to be examined recordUby 
be&o-ard in a seria.1 fashion by process routines described 

The working of the SEEK routines is described in the 
following paragraph. 
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INDEX T ABIES 
Primary Index Table 



Highest Key 
in track 

Track No. 

Length of 
secondary 
index 

Size 

Variable 

1 Byte 

2 Byte 

Example 

IC-200 

50 

80 


Secondary Index Table 



No. of records 
in sent or 

Highest key 
in sector _ ... 

Surface 

Sector 

Length 

2 Bytes 

Variable 

1 Byte 

1 Byte 

Example 

51 

0 

0 

0 


51 

* 

0 

• 

0 

• 

0 

* 


• 

• 

25 

• 

• 

IC-300 

« 

• 

2 

* 

• 

5 


Figure 6-1 
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Subroutine FKDKR Y 

Object : To locate primary key, primary key length., memory 
location of primary index table. 

Data Structure used : Relations Directory 

(ScEMT 

O utput : IREBY, IEYDT, RLOC , SREBY, SEYLT, tWE; 

External symbols : ROE ST, EEYRI, EEYRS, FMERT, FREES, 1MIEX, 

HIED, TEMP, MQ, ZERO, ME SGI. 

Working : 

The relation directory is organized columnwise. The 
relation number is taken as the offset from the beginning 
of columns and the proper value stored in output variables. 
PREEY contains primary key field identity 
I’KYLT contains primary key length 

SREEY contains secondary key field 
SEYIT contains secondary key length 
RLOC contains location of the primary index table. 
Subroutine TREDS 

Object: To find out the cylinder address and load it into 

the disk control word. 

Data Structure Used : Primary index table and CORD table. 
Output: 

TEDR Track address word 
IETTR Primary index pointer 

TOTEJTT Total number of records in the secondary 
index table. 
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External Symbols Used : CE10P, PKYLT, MI, 1RKEY, RLOG , 

IXTTR, END IX, TKDR, MESG-Z. 

3LHS It - is'- give n in- the facing page. 

Working; This subroutine puts the length of primary index 
table in variable TEFII and calls subroutine EHDIX to scan 
the table for the highest key entry which matches the key 
given in condition lable. Then it reads the track address 
from the table qnd puts it into variable TKDR. It also puts 
the length of secondary index table for that track in TOTENT. 
Seeking the Surface and Sector 
Subroutine EICSBC 

This subroutine finds out the surface and sector number 
in which the information is lying. 

Data Structure Used 

Secondary Index Table. 

Organization 

On ©very track, the surface 0 contains the index table. 
Since a track comp$*i®&ngf 100 sectors, there will be 100 
entries in the index. If all the sectors are not used, the 
end of index table will be unaltered by placing a special 
word in the NREC (No. of Records) field of the Index lable 
Working 

1. Eirst put the length of entry into X, 

2. Read the surface 0, Sector 1, into Buffer BUEF. 

3. Get the No. If Records in the index sectors from 
the first word of the BUEiBSt.. 
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4. Set pointer SXPTR to point at BUFF+2. 

5. Test whether this "bjite is zero. If it is zero, add 
the displacement x to it and g.o to next entry. 

6. If it is not zero, then SXPTR will now have address 
of the first data entry. 

7. Calculate various variables from this location as 
reference . 

At the end of this part of subroutine the following 
variables will have proper values. 

(a) SXTTR 

(b) MSEC 

(c) CTR3 

(d) NISEC 

(e) NREC (No. of records in that sector 
Now go to the other part i.e. , to FINBIX. This subroutine 
searches for the proper key field value. The exit from the 
subroutine can be either of the two. 

(a) Success*. the information has been found. I’ut SFB£K=0 

(b) Failure -.the information has not been found. Tut 
SFBOI =1. 

SFI£)1 = 1 Search Unsuccessful 

If the search is unsuccessful, the following action is 


taken 



(a) Increment sector counter. Compare its value with 
the NISEC (No. of sectors used for Index Table.) 

(h) If the sector'" counter is NISEC, there is some 
error the information has not been found in the 
index. Write a message to that effect and stop, 

(c) Sector counter = NISBC, This is the last sector 
put fflEBBO (No. of records in the last index 
sector) in NRBC increment the sector No. in 
surface sector word (SS£pR) for disk controller 
and read the next sector. 

(d) Sector Counter 4 NISBC. The sector number is 
SSUR and go to read the next sector. 

SB LOP =0 SEARCH BROM BINPEX SUCCESSFUL 

Take the following action: 

(a) Transfer the contents of sector and surface 
address in the SSUR for disc control. 

(b) Transfer pointer to number of records in this 
sector to SNCT. This will now store the location 
of the wanted record entry in the index table. 

No. of Sur. sector 

Secondary £e££*l 

Index Table — 

Index 

- _ ------- Entries 


x - 


SNQJT y 
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(c) Store the current surface and sector address 


in SAVSBC » 

(d) Clear all variables not required. 

(c) Return from the subroutine. 

EED 

At the end of the subroutine, the surface and sector 
address is stored in the SSUR and also SAVESEC. All other 
variables retain the values already mentioned except for 
CTR3 and TEMT and sector counter. 

SEEK Mechanism Einish 

Once the seek mechanism has -gone through subroutines 
TREES and FNCSEC, the track address and the sector surfa.ce 
addresses are put into the disc controller and the system 
is ready to read the corrector' sector for the required 
information. Control passes to main routine. 


SUBROUTINE COMP' 

of 

Object : In the seek phase^/retrieval, this subroutine is 

used by EINBEK subroutine. It scans condition table for 
the key field value to be compared with the value in the 
index (either primary lable or secondary lable ) tables, to 
loca.te the correct track, surface and sector number. 


BATA structure used 
1. COED TAB IB . 

Calling Instruction 

1. JMS , R5, COM! 

ARC p 1 lord containing primary key fied (rRKBY) 
ARC 2 Word containing primary key length (PKYLT ) 

AEG ^ 3 ' Pointer to location of first byte of field 
jr alue to be compared. 


.0 



Symbols Used ; CRT 2, IKE QTR . CODE , VA1C0M, FCOND, FDLGTH, 

V ALLOC , AKX, MATCH. 

Output : MATCH — 1, Means comparison success 

MATCH = 0, means comoar : non unsuccessful 
Wor king : I ni t ial i ze ; 

This subroutine makes use of Register 3 end 4 = H also 
initializes counter CER2 which keeps a track of byucs compare 
Locating the EDID in COED Table 

LI; The subroutine puts the absolute address of C0L\D iri.n 
R3. It transfer the 1st argument i.e«, the ED IDBITTITi to 
CODE e 

12; It then checks whether there are any conditions col 
up in condition table by comparing contents of EDID in C01TD 
table with zero. If it is zero, i.e. f there is no condition 
set, the subroutine branches to sjgnal success. Puts MATCHrrl' 
and goes out. 

13s If the first entry is not zero, ix compares contents 
of code with the FDID in card table. If it matches the 
subroutine branches to compare that ED value. 

14i If it does not match, then the length of the cond 
table entry is added to the R3 to point at the next EDID 
entry and branches to 13. It also keeps a count of the 
number of times this search takes place. If it exceeds the . 
capacity of table without finding that particular FD, i 

it signals an error. ED cede not found and stops. It will 
signal this condition also if it encounters a zero in the 
EDID field of COED table. That signifies end of condition 


tables 
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FD CODE IDENTIFIED BLOCK MAT 
Setting of Symbols 

Once the field code has been identified, the algorithm 
has to compare the FD value transferred from the calling 
routine with the FD value in condition table under the 
condition mentioned in the COND table. It starts trans- 
ferring remaining arguments i.e., the length of the primary 
key with FDLGTM and loc. of the FD VALUE to be processed in 
VAL10C. It stores the starting point of COFD table FD value 
in VA1C0M. It sets the location of IKE QUALITY in F COK'D , R3 
and R4 are set to point at the beginning of values to be 
compared in the condition table data buffer respectively. 

Check Whather SEEK or PROCESSING Phase Block MALL 

If the call has come from the processing phase, the 
condition which has to be tested now will be listed in FCOND, 
i.e., G-T or LT, LTB, lE’Q- etc. On the other hand if the call 
has come from SEEK Bhase then the only condition which may 
be checked is whether the FD value tested in the INDEX table 
is GTE to the value in the COND table. Since the values listed 
in the Index tables are the highest key values in that track 
or the sector, i.e., primary index table. This is sufficient 
for a single type of query where all conditions will be put 
to EQUAL. 
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PF a group query, the condition may he IE. In that case 
we must start processing from Track l. Similarly if the 
inequality is GT we should test for greater than, not greater 
than or equal to. 

This logic is done hy a group of instructions which first 
check IKY. IKY is an indicator for SEEK operation If it is 
set 


PI: If it is not 1, then go to the condition tested in the 
COED table. 

P2: If it is 1, then check condition table for EQUAL. 

If it is EQUAL go to GTE part. 

P3: If check condition is not EQUAL then go to the condi- 
tion listed in the COND table. 

Value Comparison 

Once the field has been identified, pointer set to point 
to field value location, the control jumjis to the condition 
testing blocks as per the condition listed in the COED table 
these can be: 


1. EQUAL 

2. LT 

3. GT 

4. SEE 

5. LSE 

6. NEQ 

7. AMY 


Less than 
Greater than 

Greater than or equal to 
Less than or equal to 
Not equal 
Any condition. 


The algorithm compares the field values byte by byte, the 
comparison is in the shape of (B.4-R3), i.e., value to be 
processed - value to be checked in COND table. There is 
counter CTR2 to keep a count of bytes compared. Any time a 
condition is satisfied, the program jumps to either FAIL 
or SUCCESS. 
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Success /Failure 

After every byte is compared, the counter is incremented, 
when it becomes equal to FBLGTM (Field length given earlier), 
ft jumps- to fail or success. This happens when all the 
earlier bytes have been equal and the last byte is the decid- 
ing factor. 

SUCCESSi If the comparison has been successful MATCH 
is ma.de equal to 1, A message^ is given to 
console and subroutine returns. 

FAIL: If the comparison fails MATCH = 0. Subroutine 

passes a message and returns. In either case 
Register R3, R4 are restored. 
logic of Comparison 

EQUAL (l) Compare one byte of both R4, R3. If they are 
not equal, go to FAIL. If they are equal 
GO TO FBQL1. 

(2) FEQLI Block ; increments counter, compares 
it with FDLGTH, if it is less than FDLGTM, 
increment R3 and R4 and go back to Step 1. 

(3) If counter is &T£ equal to JTECGTM, that means, 
it he.s finished comparing all the bytes since 
it has come from equal it is a successful 
comparison, i.e., CTR ^ FLLGTM - GO TO SUCCESS. 
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IT (l) Compare one byte of R4, R3. 

(2) If R4 ^ S3, i.e., sign bit is set, branch to 
success . 

(3) If R4 = R3 i.e., zero bit is set, branch to 
REQL. 

(4) If R4 R3 sign bit is 0. Go to RAIL. 

REQL block does the reverse of FEQL1. If counter is equal 
to RDLGTM, that means the two quantities are equal and LT 
is not satisfied, GO TD RAIL. 

Going to REQL and FEQL1 means the earlier comparison was 
equal. If it is the last byte, then the whole of the values 
were equal. 

GT (l) Compare one byte. 

(2) If equal go to REQL 

(3) If R4 "7 R3 branch to success 

(4) If R4 v branch to RAIL. 

GTE (1) Compare one byte of R4 and R3. 

(2) If R4 '> R3 success 

(3) If R4 = R3 branch to REQL1. 

(4) If R4 K R3 - Go to RAIL. 

LIE (l) Compare one byte of R4 with R3 

(2) If R4 J R3 - success 

(3) If R4 = R3 - EEQLl 

(4) If R4 / R3 RAIL. 

HEQ (l) Compare one byte 

(2) If they are R4 ^ R3 (zero is clear) Branch to 
Success. 
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(3) If they are equal R4 = R3, branch to FEQL. 

MY BEU to Success. 

SUBROUTINE FNDIX 

Ob ject; This subroutine scans the primary index table and 
the secondary index tables when called for by subroutines 
TREDS and FNCSBC, and gives out the location of the required 
ICBY FL value in the index table. 

Data Structures Used 

( 1) Primary index table 

(2) Secondary Index table 

(3) COND table. 

S ubroutines used ; COMP. 

S ymbols Used ; CTR1, CTR3, LOG, MBSG-9 , PRKBY, PEYLT, MATCH, 

CFLOP, UKEC , SFLOP , MESG16, MBSGIO, X, AKY-FLAG 

Calling: Instruction : JMS R3, FNDIX 

ARG1 (word loc) 


Initialization Transfer j&RG: Block A1 


It increments counter CTR3 which keeps a count of Records 


processed in the secondary index table in subroutine FUCSBC. 
It also transfer the pointer to the FL value in LOC. In 
addition it sets a flag AKY = 1 to indicate that it is a SBBK 
operation (used in COMP subroutine). It then checks whether 
there is any data in LOC. If it is zero that signifies the 


end of the Index table and is an error |Cp 


nef rint 


CENTR AL I iSRARV 

A 50871 

Ace. No. £\ .. 


a message. 
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Scan of Table 

( 1) The pointer LOC points ifco the location of 1st byte 
of the PD value to be compered. The PHDIX routine calls 
subroutine COMP to compere the values. The result is either 
MATCH = 1 or MATCH = 0. 

(2) If MATCH = 1, then the search is over and branch to 
success block SUB.SEC and return. The value LOC will contain 
the proper location of entry desired. 

( 3 ) If MATCH = 0 , then we have t o scan the next line of 
index table. Advance location by the length of the entry 
of the index table (X). Block A2. 

Locdi. loc+x - 
Loc 2=1 oc l+x 

(4) After it advances the pointer, the algorithm goes 
back to step Al, to increment counters and checking for a 
zero in the first byte of the PD value. 

PINDIX in secondary table search 

If the table being traversed is secondary table, then 
there are some additional checks to be made. As such after 
return from comparison with a Match value =0. It establishes 
whether it is secondary index lable or not by checking the 
CPLOI flag. This flag CPLOP is reset by the TEKDS subroutine.' 
It is set to 1 by the PFCSHC routine. In the end of query 
this flag should be cleared. 


Loc 

I . 
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Action for Secondary INDEX Table (Block SECY) 

Since the secondary table resides on the disc, only one 
sector is brought into the Memory h j At this time NHEC 
contains the number of records in the sector. As the checking 
proceeds on the information, counter 1 CTR1 keeps a track of 
records processed. If this counter becomes equal to number of 
records, i.e., IB CTR1 = NKSC that mean all the records in the 
sector have been processed with no match found. It then sets 
a flop SFLOI to 1 to signify failure as far as this sector is 
concerned and returns to the subroutine BTC SBC f which will 
bring in a new sector of the index table and recommence search. 
Suc cess 

Once the desired enxry has been located, the subroutine 
prints an exit FNDIX message and returns. 

Errors 

If no match is found it prints a message INDEX TABUS OVER 


and stops. 



7. PROCESSING SINGES OFFICER QUERY 


The search for information can he of the following types: 

(a) search for particulars of one officer 
(h) search for a block of officers 
(c) search an entire file. 

The factors involved in all these types of searches are dis- 
cussed in this and the following chapters,, 

Individual Officer Search 

In this type of search, one individual key like the per- 
sonal number of an officer is given and one or more other 
fields information is desired, In example - 
OUTPUT (a) Date of birth 

(b) Year of commission 

(c) Qualifications 

(d) Next to kin 

for Personal No. IC-2000, Capt. S. SINGH. 

The fields on which information is desired may be from 
one relation or may span more than one relation. The personal 
number being the key for all relations, except for the inverted 
files, all such relations can be scanned. The method of 
search employed will be the standard procedure for search 
based on primary key. This method is outlined below: 

Method of Search and Proces s 
1. SEEK 

(a) Select the first relation 

(b) Scan the primary index table and the secondary 
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index tables to locate the physical sector 
on the disk. 

(c) Bring the sector to the main memory buffer. 

2 . Process 

(a) Search this buffer on the primary key and locate 
the particular record. 

(b) Extract the fields desired t o be put out and put 
them in output buffer. 

(c) Check whether all fields required have been obtained, 
if yes, go to (e). If not go to (d). 

(d) Obtain the next relation and go to back to 1(b) 

(e) Arrange the output in the subschema format (Bata 
sub model) and print. 

(f) Co to end Routine. 

In this type of processing sectors of the current relation 
being processed can overlay the buffer of the previous relation, 
The change over of relations require no reassignment of pointer, 
buffer. The routines used in this type of query processing 
are : 

(a) SEEK 

(i) FNDKEY 

(ii) FNCSEC 

( iii) FIKDIX 

(iv) COMP 

(v) TRKDS 

(b) PROCESS 

(i) IROC 
(ii) OTPTo 
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SEEK 

The method of finding out the physical sector/block 
and how to bring it into memory has been explained earlier. 
Once the information is in buffer it has to be processed as 
detailed below. 

SEARCH IE -Buffer 

The location of the record in the buffer has to be done 
by a sequential search. Provision also has to be made for 
skipping a blank or deleted record, and errors signals to be 
provided if identification of record is not obtained. Such 
steps are out lined below. 

SI: Read, a record 

S2: Check primary key field 

S3: If it is a blank or key value does not match the 
key given go to S4. Else go to S5. 

S4: Is it end of sector or end of file'; If yes signal 
error else advance pointer and go to SI. 

S5; Check fields required by the 0T1T table and put 
them in the buffer. 

§6: Arrange fields as per subschema. 

Information in Tables 
COED 

In this type of retrieval, there will be only entry in 
the COED table, that of personal number, EQUAL Value 


01 


VALUE 


EQUAL 
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This value will he cheeked every tine a ^record has to- he 
checked. 

Process and OTPT Tables 

In a general case the TBIROC has to he scanned to check 
all the fields which have to he compared in every relation. 

L pointer is positioned at the head of buffer. Field are 
selected from the TBIROC and successively compared with values 
in buffer records are processed till a record is found which 
matches all the field conditions of one relation. Then 1R0C 
takes on the next relation and so on. 

In the single query, the above method is not referred, to. 
The only field to be compared is Primary key field. If we 
were to follow the general method for every relation to be 
processed the personal number will have a corresponding entry 
in TBPROC. The structure of the TBPROC/TBTPT will be as in 
the table given below: 

TBIROC 

~EBL. 10. _FDIP RD IBNGTH RDIST ACTION 

R1 01 8 0 1 

R1 03 4 8 0 

R2 01 8 0 SO 

x. R2 05 4 12 0 

R3 01 8 0 0 


R3 


07 


10 


12 


0 
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We see here that ST 01 which is the key field for all 
relations cones in for comparison in every relation. Also 
care will have to he taken to see that it is not repeated 
in the OTIT of every relation. This complication is avcridaw 
ble for single query and the modification is described below. 
Modification 

We know that the primary key field is the first field of 
every relation. The distance from the beginning of every 

record STIST = 0. Its field identity known as well as its 

A 

field length. 

Once we have this information in memory, we put STIST=0, 
bypass the TBBROC scan and start comparing the value in the 
buffer to with that given in the CORD table, 'When a match is 
struck pass on to OTTT routines. 

Bor this query, the TBPROL/TBOTrT may not contain the 
key field entry at all unless this key is also desired as 
the output field. 

Stopping the Algorithm 

This algorithm deals with only one particular record 
p fgj g» relation. Once this record has been located, all fields 
output, the system should stop and give a message job over. 
If the information is not found in that sector, then there 
is some error and an error message should come. Thus the 
algorithm should stop in the following states. 

(a) JOBOVBR after OTPT routines over. 
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PROCESSING SINGIE QUERY 




Layout TBPROC 


EEL 

ID 

FD 

ID 

FD 

LGT 

FD 

DISI 

Action 


R4 

1 

8 

0 

1 


R4 

5 

2 

12 

0 


R4 

8 

4 

14 

0 


R5 

10 

4 

8 

0 


R5 

0 

0 

0 

0 


De tai Is 






FD 

Length 



FD 

Length 

EEL 

LGT 


EEL 


' LD6 

4 01 

8 


5 

01 

8 

03 

4 



10 

4 

05 

2 



15 

2 

08 

4 






Figure 7-1 
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2. Error in Sector 

If it is first relation and the officers record is not 
found, there is error in SEEK. Give error message. 

ChdOks la'-Be 

Once the SEEK is over, the only checks to "be made while 
processing are: 

(a) Is it a Hank record. If yes go to next record. 

(h) Is it end of sector. 

(c) Is it end of file. 

These checks have to he made every time a record is pro- 
cessed. In case it i s case (b) or (c) and it is not relation 
1, the output should be filled with blanks. In case of 
Rel. 1, signal error. 

METHOD OF IROOESSBfG 

The method of processing is illustrated by an example. 
Take a case in which information is to be obtained from two 
relations Rel 4 and KS$ 5. The layout of these relations and 
the structure of TB1R0C is given on the facing page. The 
first relation to be processed is RBI 4. 

SEEK 

The seek mechanism puts a sector of RSI! 4 in the memory 
buffer BUFF . vW &-V- W- The seek mechanism 

also gives the following information 

1. ERSC contains no. of records in that sector 

2. RECI0VI contains records length 

3. KEKID contains relation ID. 
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2RQC 

The processing algorithm first transfers this information 
to the variables mentioned (Block T ARG-). 

It then checks for type of query by TST SIHG-IE. In 
SHTGIE case i.e., SIHGIE = 1, BUST = 0, FDLG-T = 8. 

This inform at ion is put into two variable s, KFD1G-T, KIT’D and 
transferred c .^al$-o-yfco* %i variables FDLOC, FBLG-T. Row the 
portion of processing TBIROC is bypassed. A pointer BUFFTR 
is positioned at the start of BUFFER in the beginning and it 
keeps an incrementing by RECIGI to keep pointing at the head 
of successive records. Another pointer TEMI Is utilized to 
point to the location of the field, which is being processed. 
In single query TEMI and BUFFTR will coincide at the beginning 
of every record. 

After the checks have been cleared, the identification 
field has to be compared. Block IDEHTF calls forth COMB. 

If the output MATCH = 1, then the process passes on to OTDT 
to output desired fields. 

If the field does not match, the control branches off 
to NXREC which checks for record count and increments record 
counter. It adds record length to BUFFTR. Then it branches 
back to G-TFB to start processing next record. 
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lr an.sita.on from One Relation to Another 

In a single query the transition is ea sy. There is no 
field to be passed on to next relation. Just select the next 
relation from TB1E.0C and start overlaying new information 
on the buffer. 

Processing End Conditions 

It may happen that a particular rele.tion information ma.y 
not exist for that officer. For example, IC-20000, Capt. 

I’ . KUMAR may not be a graduate . As such his name will not 
figure in the relation QUA1. In this case, the seek mechanism 
will put a sector which should contain the informa.tion if 
it exists. An end of sector will be encountered without 
matching the key. The processing should not stop here but 
should go to next relation in TBIROG/TBOTIT and should fill 
blanks in this officer’s qualification field. In the last 
sector End of File may similarly occur. The action will be 
same in this case. Only in first relation should the error 
be signalled in case of End Sector or End File Condition. 
Important 

The first relation in the query should be one containing 


all officers data,. 





























8. GROUP QUERIES 


There may he two types of group queries: 

(a) Queries about a group in which a subset of the 
complete relation is to be searched. 

(b) Queries covering an entire halation. 

Subset Search 

There will be some condition on the primary key by which 
a particular block of information will be checked. The re- 
trieval is in two phases - 

( 1) Seek the file portion which meets with the 
primary key condition. 

(2) Process the relation. Keep a check on the 
primary key value and stop the job once the 
primary key value goes out of the range 
specified. 

Example: Print out 

Rank 

Name 

Unit 

of all officers belong to corps of engineers. 

In this case relation No. 1 will be CORPS and search will 

commence when key vafue equals engineers and stop when the 

key value changes. 

Example 2 P rint out 

Rank 

Name 

corps 

of all officers v hose personal number is less 
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than IC— 10000. The job gets over when the hey value be- 
comes IG-10,000. 

Full Relation Search 

This normally follows a search based not on primary hey, 
se arc h starts from the 1st sector of the relation and goes 
on till END of file has been reached. 

Example 

Print out the names of all officers whose state is 
MAHARASHTRA and whose date of birth is less than 01 January 
1940. 

Differentiation Between Queries 

The first level of differential ion comes from putting 
a variable SINGLE. Now we use another variable GROUT. If 
GROUT = 1, it means the query is on primary hey and a subset 
of a relation has to be searched. This condition has to be 
tested only after SINGLE has been tested. When both of them 
are zeroes it will mean a full relation search. 
Characteristics of a Group ENQUIRY 

The special characteristics of group queries are listed 
in the succeeding paragraphs. 

1. END OF JOB 

In a single query the job Is over, once all the fields 
of OTIT table have been covered. The system then returns 
to initial conditions. 

In a group inquiry, after the DTTT lable has been 
covered once, the system proceeds to next officers records. 



66 


It has to go hack to the first relation end start processing 
from the point it last processed. Bnd of job will come when 

(a) A mismatch of primary key occurs or 

(b) It reaches BND OP P IDE in relation No. 1. 

These checks have to be made after every print out. 

2 . No. of Pointers to be Kent 

Since the processing returns to the first relation after 
every successful record output, the pointer to the last record 
processed in Relation No. 1 has to be kept. 

Also one pointer has to be maintained for every relation 
which is an inverted file or in which every record does not 
have a unique primary key. 

3. No, of Buffers Used 

In a single type query only one buffer is sufficient as 
no return to any relation is required. In a group query one 
buffer is required for the first relation in the TBIROC and 
one general buffer for other relations. In addition, one 
additional buffer will be required for each of the inverted fi 
relations, in which pointers have to be maintained. 

4. Transition from One Relation to Another 

In group query, the following information has to be kept 
a. live 

(a) Buffer for first relation 

(b) Tointer in first relation to record last 
processed 

(c) Buffers and pointers to inverted file relations. 
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The transition from one relation to another must not 
disturb any of the above. In addition, COND table entries 
have t o be changed at every transition and old value remem- 
bered. 

Example 

We may be processing relation CORES based on ED = 02, 
i.e., parent arms of the officer. The relation may loot 
as given below: 


Corps 

Personal No. 

Name 

Rank 

02 

01 ' 

03 

04 

03 

10-10 

PZR 

Capt 

03 

IC-20 

TCX 

It. 

03 

10-25 

ABC 

Lt. 

03 

10-30 

DYZ 

2/Lt 


Once we have to search on ED02 = 03, i.e,. Corps = Engineers, 
then the personal number condition becomes equal to ANT 
because all the above officers belong to Corps 03, The first 
relation will be brought into memory with a sector in which 
Corps = 03. Each officer will be taken one by one and his 
attributes in other relations found out. Eor other relations, 
it is like a SINGES officer search every time one officer r s 
record has tote processed. So when we are examining" 10—20 
TC2>, the COND table will record PERSONAL NO. EWES IC-20 and 
PERSONAL NO. ANY once t his particular officers attributes are 
over. The change over from AN Y to EQUAL will be done after a 
successful hit in the first relation and will be changed back 
to ANY after the last relation in TBPROC has been processed. 
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5* Action of Error Messages Gome 

As in the case of SINGES QUERY if an end of file comes 
in the first relation, the job is over. And end of file in 
the other relations means blanks have to be filled in those 
fields and proceed to next relation. 

Every time a changeover of relation is taking place the 
action as described above has to be taken. In this case since 
personal number is the primary key of all relation except of 
Relation No. 1, the personal number of every officer can be 
put into KYFD and KFDLGTM. No change in COED YIELD will be 
required and all relations except for Relation No. 1 will 
take their personal number keys from KYFD instead of COFB FIELD. 
S equence of Processing Group Queries 

Gl. Initial! ze : Set SINGLE = 0, NEEL = 0, set pointer to 
beginning of buffers. 

G2. Select the first relation. 

G3. Seek the beginning of a group required in first relation, 
such a particular record in all other relations. 

G4. Process the record against TBPROC. 

G5. If found OK put personal number in KYFD. Store the 
pointer in buffer in case of first relation, 
u 

G6. Rroceed to OTPUT routines. 

G7. Check whether all fields of this relation to be processed 
or over. 

G8. If yes, save buffer and pointers settings, go to £ G10 
else go to next G9. 

G9. Bring in next field relation. Go to G4. 
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G-o To Process First Relation 









G10, 


Check whether all relations over ? £f yes Go To It 
else follow. 

Gil. If ft is first relation, change buffer setting to BUFF 2 
change values in KIFD, EFD1GTM. Br^ng in'new reiat^on 
and go to G4. If it is not first relation noshsjnge'in 
settings required simply overlay. 

G12„ All relations over. Print OTPUT. Check whether query 
is over. is If yes, GO TO G14, else G13„ 

G13„ Change buffer settings to Buff 1. Go to process Relation 
Fo. 1 (G4). 

G14. Go to End routine. 

Act ion at the end of Sector Routine PROC F 
F xit f rom Process 

While processing a particular sector in a particular rela- 
tion the following situations may arise. 

(a) End of Sector. 

(b) End of Relation. 

In either case, there will be an exit from the PROC routine 
with a failure indicated by SWITCH2 = 0. The exit will also 
set another flag SWITGH3. SIWTCi&^Of or end of sector and 
SWITCH3=1 for end of Relation. The action to be taken is as 
described below and is also indicated in the flow chart. 

E nd of Sector 

The end of sector action varies with the relation. It 
also depends upon whether it is a single query or a group query, 
(a) First Relation 

(i) If it is a single query end of sector means 
end of job. 

(ii) If it is a group query it means action to go 
to next sector. 
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( b ) Relation not First 

End of sector signifies filling up the fields of the 
relation with blanks. 

Incrementing Sector. Surface. Track 

The following logic applies in incrementation. 

1. Increment sector count. Check whether it exceeds 
10* If so go to increment surface count and reset 
sector count to 1. 

2. If the surface count exceeds 9, then go to next 
track from seek subroutines and primary index table. 

3. If the track count exceeds number of tracks used as 
mentioned in Relation table mark END OR JOB. 

END OR RIDS 

If it occurs in first Relation then it means end of job. 

In any other relation it will mean filling up blank for that 
relation and go to output routines. 

Error 

Exit from Proc. on any other account means error condi- 
tion. Stop and give an error message. 

Conclusion of Processing 

Once the officers record has been processed and put in 
the output buffer, the routine EOIPI takes over and rearranges 
the output in the format of the subschema supplied by the 
user and control goes back to MAIN routine. 









9. OUTPUT ROUT TUB 


The processing routine, prepares a buffer for output 
in which the various fields are arranged in the order in 
which they appear in the table OTPT. This may not be the 
order in which the user requires the output. Thus another 
routine takes over which rearranges the order of the fields 
as per the requirement of the subschema. 

F ormat 

At the end of the process routine, the output buffer 
has the following shape. 


FD 

IDENTITY 

FD 

LENGTH 

VALUE 

TOH 

R£ 

PC 

IDENTITY 

MSTH TAM 

1 Byte 

1 Byte 

Variable 

1 

6 




Fig. 9-1. layout of buffer at the end of processing. 
The desired format will be as per subschema and will have 
the following shape. 


FD VALUE 1 blanks FD VALUE 2 


xxxx 


012 


Figure 9-la. Final output 
Routine Working 

Every time the OTPT routine prepares a line to be 


printed, it hands over to OUTPUT routine. The output 
routine makes use of the following data structures 
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(a) SBCHMA 

It picks one field at a time from SBCHMA and scans the 
buffer for this field. On finding this field it puts the 
field length into a counter and transfers that many bytes to 
a temporary storage area. 

C heck Tyne of Field 

It then reads the type of the field f rom SBCHMA, If 
it is numeric field, it has to be converted for printing. 

If it is alphanumeric it can be transferred straight. After 
conversion, this value is stored in the output buffer. Then 
the desired number of blanks are put in the output buffer. 

This information is also to be stored in the SBCHMA. 

Pr inting 

Once the output buffer is ready and the end of SBGHMA 
has bec-n reached a command is given to the printer to print 
the desired information from output buffer. The whole line 
is printed and control goes back to process routine. 

JO B OVER 

Once the job is over, a message should come to the 
console and the printer. The printer skips a few lines and 
prints out a line of dashes to mark the end of table. The 
console prints out JOB OVER and the system returns to original 
state ready to accept new commands. 



10. RECOMMENDATIONS 


Due to the frequent failure of the TDC-316 system es- 
pecially the input-output devices, it has not been possible 
to subject the system developed through rigorous r -te&ts. While 
working with the system, the following areas have shown need 
for improvement in design. 

1 * Query Translation 

(a) At present the user needs to know the field identi- 
fication for preparing fields. The subroutine operates on 
the numerical value of this field. It should be able to 
opera te on the names of the fields given. 

(b) There are three sets of cards to be f ed in for making 
data structures 

(i) TBPROC 

(ii) COND 

( iii) SUBSCHEMA 

It is possible to reduce the number of sets to only two * 
TBPROC and COND can be combined. It will also aid in avoid- 
ing errors during processing arising out of differences while 
creating these data structures. 

2. OUTPUT 

As yet the system is geared for ^Sputting out ASCII 
coded information only. The final output routine EOTPT can be su 
suitably modified with NOWR routine of DB routines to handle 
binary information to be output. 
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( o ) Data Structure Size 

The data structure sizes have been a.rbitrarily decided 
to meet normal operating conditions like 

1. COND Table can handle 10 conditions 

2. Max. '.field size for comparisons is 8 bytes 
so names cannot be a basis of search. 

The sizes of the data structures can be modified to suit 
individual system requirement. 

(d) Inverted File s 

The system operates on one inverted firle only. To in- 
corporate more inverted files suitable modications will 
have to be made in the MAIN routine. Also, • additional 
buffer of 256 bytes have to be reserved for each additional 


inverted file. 
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APPENDIX 1: Method of Using the System 


The information retrieval system occupies memory space 
from 60,000 to 72,000 (octal address). The routine approach 
starts at 72000. The system makes use of the following 
external routines: 

(a) SOM called by letter SO line feed. 

( b ) Read 

(c) SET. 

Calling Instructions and Dialogue 

The routines are placed in the system area of the disk 
and are placed with KDM. The procedure is as follows: 

1. load KIM 

2. Start from 0173500. /in asterisk will be typed 

on the teletype. 

3. Type ’SC 1 line feed. An asterisk will again be typed. 

4. Type * AP * If. Approach will be loaded. 

5. Type ’MU’ If. Main will be loaded. 

6. Set address 7BOOO from console and press start. 

It will start the dialogue. 

Dialogue 

The starting message will be 

GIVE ID NO. 

Fill in the ID No. for that day (at present 123) and press 
IF. If the number is incorrect, the teleprinter will type 
a message. 
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'UN AUTHORIZED USSR 1 and start ringing the hells. 

Start again from 72000. 

If the ID is correct, the following message will be 
typed; 

USER VERIFIED PROCEED - 
FOR UPDATE TIPS IN U 
FOR RETRIEVE TYPE IN R 
IF DBA TYPE IN D 

Press R LF then the system types out 

STARTING RETRIEVAL, INDICATE TYPE OF QUERY 
IF SINGLE OFFICER QUERY, PRESS S, ELSE G IF 

Here the system finds out the type of query from the user. 

If proceeds differently in both cases. In case of single 

query, the only entry in condition table will be his personal 

number. 

Action on Single Query 

If you press S LF the system will type out 

SINGLE QUERY, IF INPUT DEVICE RARE PRESS ‘O’ LF . 

IF INPUT DEVICE KEY B PRESS KF LF. 

Depending upon the type of input device press C or K LF. 

The machine then types out 

TYPE IN LEVEL FDNAMS , FDID, JOB ON THE FD. 

Definition for FIELDS 

The user has to now give the list of fields which he 

wants to process or output the format of this information is 

02 x ^ 

Any 6 characters. First character to be an 

alphabet. _ „ 

FD No. 1st letter should be F e.g. , F7 or HO f. 

Blank for 0, 9 for putting 1 in TBPROC, 99 for 
nutting 2. (0 means output only, 1 process and 

x output, 2 process only) 


Level 

FDNAMS 

FDID 

JOB 
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Put a blank between each entry and end with a (.) IP. 

e.g. , 

02 j6 NAME P01 i> 9 # . IF. 

The system prints out the message e.g . , field def«naition 
and asks for NEXT PD. Type in all the fields and finally 
end the field listing with (.) DP which will put zeroes 
in the last entry in the table for processing and output 
and print out 

ALL FIELDS OVER PRINTING TABID POR PROCESSING 
AND OUTPUT. 

Theh are the table is printed out. It consists of ten 

lines each of five entries. 

The columns are as follows: 

1st Relation No. 

2nd PD No. 

3rd Pie Id length 

4th Distance of field from beginning of record 
5th Job to be done on this field. 

After it prints out the TBPROC, it prints a message 

TIPE IN PERSONAL NO. 

Pill in the personal number and press LP. The system 
registers this personal number and then gives message 
COND TABLE OVER GIVE SUBSCHEMA. 

It also asks for choice of INPUT DEVICE, keyboard or C&rd 
output. Now give the list of fields in the order in which 

the user desires them to be output, e.g., 

PI 

F5 

F6 

F4 
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The definition of the fields will be in the same pattern 
as described earlier. Every time a field has been entered, 
the bell rings for a new field. End the subschema with a 
(.) LF. The system then types 

SUBSCHEMA OVER 

JOB OVER 

PRESS CONTINUE TO START RETRIEVAL. 

Press continue to start retrieval of inf ormation. 

Group Query 

When you press G in response to type of query it finds 
GROUP INQUIRY GIVE ED ON WHICH SEARCH IS BASED. 

In response to this message type in the field specifications 
on which the search is based. It i s primarily meant to use 
for retrieval of inverted file Relation 1, which is based on 
FD 03. The system types out the details of field and asks 
for choice of INPUT device. Then the dialogue is same as 
for SINGLE query till the printing of TBPROC is over. Then 
to build condition table it again asks for choice of INPUT 
device. Once the input device is mentioned it asks for 

GIVE CONDITION FD 

Specify the FD No. as done earlier. The system registers 
it and asks 

GET VALUE. AFTER VALUE GIVE ONE BLANK LF 
Type in value and press LF, The value is registered and the 
system asks 


GIVE CONDITION. 
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Type in the condition for this field may be 

EQUAL 

NEQ 

GT 

GE 

LT 

IE 

ANY and press LF. 

The system registers this condition and goes back to ask 

GITS CONDITION ED. 

The user fills up all the condition entries and then as the 
last entry enters (.) IF. 

The condition table is over and now the system goes to 
make subschema. The dialogue is same as for single query. 
In case the user selects the card as input, all the condi- 
tion field entries are put on the card. See example below. 
CARD INPUT FOP THE SYSTEM 

There are three series of card inputs. These are in 
the order and format given below. 

For TBPROC 

02 i XYS $ FI i 9/99/36 36 • LF 

* 

0 u LF - (last card) 

For COND Table 

02 / XYZ $ FN' $ . VAL / COND 

% 

02 ABC F 2 . 100 EQUAL 


0 . LF (last card) 
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For SUBSCHEMA 

Since these are only output cards 

02 i> JME # FN i i> $ . IF 

* 

0 . IF 

cards for all the groups can he kept on the card reader in 


one stack 



APPENDIX 2. Programme layout 


The programme is divided into the following parts 
with starting locations as shown: 


MAIN 

location 

60,000 

SEEK Routines 

(a) ENDKEY 

62,000 

(b) END IX 

62, 400 

(c) TRKDS 

63,000 

(d) ENCSEC 

63,300 

Processing Routines 

(a) Proc. 

64,000 

(b) Proc F 

64, 600 

OUTPUT Routines 

(a) 0TP5J 

65,500 

(b) EOTPT 

66,200 

Query Translation 

(a) Approach 

72,000 

GEN ROUTINE COMP 

61,332 

GEN. VARIABLES 

67,300 


These routines have already "been described in the various 
chapters. MAIN routine calls the other subroutines iu an. by 
tir-h for retrieval. 

In addition it makes use of external routines from DB. 
These are 


(a) SC id! 

(b) GST 

(c) BEAD 

(d) SET. 

These routines are loaded from 20,000. After calling EDM. 
lo ad 15-. 
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LISTING 

The listings size does not permit it to he attached 
to this thesis. Copies of listings are kept in the computer 
centre library. 

Functions 

The main routine is the controlling routines. The 
SEEK routines locate the relevant sector of information on 
the disk and put it in memory buffer. The processing 
“routines then process the information in the buffer. The 
output routines prepare output buffers as per the subschema 
given by the user and output it. 

The query translation elicits specifications from the 
user and prepares data structures, COIL TABLE, Processing 
table and Subschema. 



APPENDIX 3. Working with TDC - 316 


This project was taken up on TDC— 316 especially to try 
out the TDC-316 system with an intensive usage. The project 
has teen successful in this respect as it has subjected the 
TDC-316 to real heavy loading. The system at the Indian 
Institute of Technology, Kanpur has proved to be very un- 
reliable with a very heavy down time. The main points 
observed are listed below; 

1. CARD READER ; Break down in blower system, too 

frequent pick checks, resulting in 
heavy loss of input time. 

2. PRINTER ; An old model printer which gave exten- 

sive trouble in paper feed mechanism 
for over a month and a half. 

3. DISK? : No protection of system programs possi- 

ble. Disk heads got damaged once. 

Disks scratch very early. 

4. KEYBOARD : Off line OK. ON LINE possibly due to 

bad connections at CPU gives very fre- 
quent troubles. Also the model is 
light duty model, should not be used 
more than 2 hours at a stretch serious 
time taken 

5. PAPER TAPE : By and large satisfactory. 

SYSTEM ; 

6. C0NS02S ; Almost trouble free. Power supply gives 

trouble. 

7. CPU : Frequent troubles in disc controller. 

Hardware bootstrap and keyboard cards. 

8. MEMORY ; Very good. Except for failure in power 

supplies it has been trouble free. 
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Due to frequent failures of the PERIPHERALS, the system 
■was almost totally off from April to mid-June 1977. Even 
when all other subsystems are working fine, the inefficiency 
of the card reader increases the assembly time/compute time 
very badly. 

Software 

The KDM worked satisfactorily. BAD has also proved 
efficient in assembly and execution. Assembly Language 
Programs use very small memory space. COPY routines did not 
work while creating an object tape from DISK. 

Due to lack of protection on the disc and inefficiency 


of the card reader, it is strongly recommended to users 
to create object program paper tapes during assembly for 
future input . 



